PATH
PATH
MacOS X Server Release Notes Copyright \xa9 1998 by Apple Computer, Inc. All Rights Reserved.
These notes are for the Mac OS X Server (formerly known as Rhapsody) release of the compiler. This compiler is based on the GNU C compiler, version 2.7.2.1. It compiles programs written in C, C++, Objective-C, or Objective-C++.
The following new features have been added to the compiler since the first developer release of Rhapsody.
All compilers now understand the following pragmas:
#pragma options align=word#pragma pack(n)These pragmas affect how fields are aligned within structures.
Normally, fields are aligned on natural boundaries in such a way that
32-bit (and larger) quantities are 4-byte aligned. However, when you
use the option align or pack(2) pragmas,
fields whose size is at least 16 bits are aligned on even
addresses.
This feature is not currently supported in the PDO or Windows NT compilers.
The cc command line flag -fpascal-strings enables
the compiler to permit Pascal strings to be recognized. A Pascal
string is a string containing an initial "\p". During compilation,
the string's initial "\p" will be replaced with a byte containing the
length of the string (not including the "\p"). The type of such a
string is unsigned char *. It is an error
for any pascal string to be longer than 255 characters. When a "\p"
is seen in a string and the -fpascal-strings flag is not
given, the compiler will issue a warning (just as older compilers do)
about an unknown escape sequence.
The c++ command can be used to compile C++ source code. This comand, in turn, invokes the cc command. Some third party software look for this command during the build process.
The preprocessor now searches the directory /usr/local/include by default as a last resort when it is looking for header files.
Although they are not new, the following features are not documented elsewhere:
In order to make use of exception handling features, you must use the -fhandle-exceptions switch and link with the System framework. See the section on known bugs for caveats related to the use of this switch.
The C++ and Objective-C++ compilers no longer switch the list of
valid keywords when they see the extern "C" construct.
This may cause existing C++ and Objective-C++ code to fail to
compile. The extern "Objective-C" construct can still be
used, as in the past, to switch to a mode in which C++-specific
keywords such as "class" and "template" can be used as
identifiers.
The header files have been sanitized and no longer use C++ keywords as parameter names, struct field names, or function names. (Rhapsody header files have undergone the same kind of scrutiny as OPENSTEP and PDO files.) The updated header files should make using C++ on Rhapsody easier (than on OPENSTEP) and more like other C++ development environments.
Before you re-compile C++ code with this new compiler, you might
have to rename certain constructs in your C header files or use
extern "Objective-C" instead of extern
"C".
In general, you should be able to include any Windows header file in an Objective-C source module without problems. The System framework contains Microsoft's header files, with slight modifications to make them compatible with gcc. For instance, slight changes have been made for unnamed unions, Microsoft assembly, and so on. If you have problems including any of the Windows header files, try including the file winnt-pdo.h before the Windows header file that's causing problems.
The -Wmost compiler flag is equivalent to the Free Software Foundation's -Wall, except that it doesn't turn on -Wparenthesis. The -Wmost flag also suppresses warning messages about static constants that are not actually used. This flag is for internal use, and its definition may change in a future release.
Please ignore documentation on the -Wmost flag in the section Options to Request or Suppress Warnings of the compiler manual.
You can now specify frameworks on the linker and preprocessor command lines. The -F flag is accepted by both the linker and the preprocessor, while the -framework flag is accepted by the linker only. The -framework flag is documented in the section Options for Linking of the compiler manual, and the -F flag is defined as follows:
In your Objective-C code, include framework headers using the following format:
#include <framework/include_file.h>
Where framework is the name of the framework (such as AppKit or Foundation; don't include the extension) and include_file.h is the name of the header file to be included.
Please ignore documentation on the -framework flag in the section Options Controlling the Preprocessor of the compiler manual.
If the name of your source file ends in .cc, .cxx, .cp, .cpp, or .C, gcc attempts to compile your program with the C++ compiler. Similarly, if the name of your source file ends in .M, gcc attempts to compile your program with the Objective-C++ compiler. Although the Objective-C++ compiler does recognize the .mm extension, the Project Builder makefiles do not curently support compilation of files with that extension (see known bugs).
The compiler includes two new options to assist in debugging. Specify the -H flag on the command to have the compiler emit a listing of included header files (indented to reflect where they are included). Specify the -dM option after the -E (preprocess) option to get a listing of all macros along with their full definitions.
Avoid using the -posix switch; there are no POSIX-specific libraries.
Although keyword-switching no longer occurs inside a context
tagged by the extern "C" linkage directive, the C++
keywords are turned off inside an extern "Objective-C"
{...} range. When entering and exiting this context, the
actual switch in keyword sets may occur a token or two late, meaning
that you may get syntax errors on legal code. For example, if the
first token following an extern "Objective-C" range is
"class", this will be interpreted as an identifier and not the C++
class keyword. You can work around this by re-ordering your
declarations or inserting a dummy declaration after a
keyword-switching boundary.
Gcc extends the C language with a feature that allows one to nest function definitions, and pass pointers to nested functions. However, this compiler crashes when processing code that involves pointers to nested functions.
(69211). Programs on Windows NT must add explicit references to at least one class in each framework in order to avoid link errors at run time. For instance, you could add a function like that in the following code excerpt, which refers to classes in each of Enterprise Objects Framework's layers. Though never invoked, it forces the appropriate linking to occur.
#ifdef WIN32
#import <EOControl/EOControl.h>#import <EOAccess/EOAccess.h>#import <EOInterface/EOInterface.h> void _referenceAllEOFrameworks()
{
[EODisplayGroup new]; // EOInterface
[EOEntity new]; // EOAccess
[EOEditingContext new]; // EOControl
}
#endifIf you create a project with the type "EOF Application," this code is automatically added to your project main file.
(63746). The precomp-related options are not yet supported on Windows NT.
Unless constant strings (both char * and NSString)
are 7-bit, your code will not be portable because compilers deal with
8-bit strings in a machine-dependent encoding.
(66861). If you create an executable using the Windows NT compiler, and don't use the -o flag to explicitly tell gcc what to name it, gcc will most likely give it a random name.
(61306). The -pipe flag doesn't work in the Windows NT compiler.
(67853). On other platforms, when the compiler crashes (a rare event), it might generate some assembly language output before it goes down. If you use the -pipe flag, the assembler may not be able to detect the fact that its input is incomplete. As a result, the assembler may produce an incomplete, but valid .o file. If you use the make utility to build your application, make will detect the fact that there was a problem during compilation. However, when make is subsequently invoked, it might not recompile the source file that caused the problem, and the linker will probably complain about unresolved external symbols.
(69156). When compiling C++ programs that use C++ streams with gcc on PDO platforms, if you specify the -ObjC++ flag you must also specify the -lstdc++ flag. So, for example, a program "foo" that uses cout (and therefore includes iostream.h ) would be compiled using gcc as follows:
gcc -ObjC++ foo.cc -lstdc++
(69087). On Windows NT, the compiler sometimes tries to create a
library instead of an executable when a function is declared as
__declspec(dllimport) (perhaps in a header file), but
the function is actually defined in the file being compiled. The
workaround is to remove the offending
__declspec(dllimport).
(69506). On Windows NT, if a function is forward-declared to be
stdcall but not declared to be stdcall in
the actual function definition, the compiler will emit code to pop
the arguments off the stack, but won't adjust the function name.
(70212). On Windows NT, if you're building a framework and you
create your own DEF file for it, defining exported objects as
CONSTANT will produce a warning from the linker advising
you to use the word DATA instead. If you substitute the
word DATA for CONSTANT in your DEF file,
some or all of your objects won't be exported correctly; the linker
will be unable to find them. As a workaround, simply leave the
declarations CONSTANT and ignore the linker
warnings.
(70326). The -static and -dynamic compiler flags are meaningless on Windows NT and shouldn't be used on that platform.
(2257397). The -dM compiler flag causes the Windows NT preprocessor to go into an infinite loop while printing the values of macros that are defined at the end of a compilation. This flag shouldn't be used on that platform.
(54831). The PDO compiler cannot apply a user-defined constructor to a global or static C++ object and send an Objective-C message in the same file. To work around this problem, eliminate the constructor, the global, or the Objective-C code.
(38759). The compiler generates wide-character literals for the host endian-ness only. For example, if you are cross-compiling the string L"x" from m68k to i386, it will be a big-endian wide string. The only workaround is not to cross-compile modules that depend on wide characters.
ints to floats.__declspec(dllexport)__stdcall are handled properly
now.Assuming you have installed the sources package, the steps for building the compiler from scratch using the provided source code are as follows:
1) Create an empty directory and make it your current directory.
2) Type the following command:
/System/Developer/Source/GNU/gcc/configure --target=`arch`-rhapsody
--srcdir=/System/Developer/Source/GNU/gcc
3) Delete the line that reads "BISON=/usr/local/bin/bison" from the Makefile the previous command created.
4) Type the following command:
make bootstrap gnucompare LANGUAGES="objc objc++ c++"
HOST_PREFIX="`arch`-" HOST_PREFIX_1="`arch`-" HOST_CC="cc -arch
`arch` -traditional-cpp" GCC_FOR_TARGET="./xgcc -B./
-traditional-cpp" BOOT_CFLAGS='-O $CFLAGS -traditional-cpp' CC="cc
-arch `arch` -traditional-cpp"
The most important files of interest that result from this are xgcc, cpp, cc1obj, cc1plus, cc1objplus, and specs.